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REMARKS 

In response to the Office Action mailed 15 March 2006, the Applicant respectfully 
requests the Examiner to reconsider the above-captioned application in view of the above 
amendments and the following comments. 

Claims 14-18 and 20 were previously pending and allowed in this application. 
The Examiner has sua sponte withdrawn the allowance and rejected all pending claims. 
Claim 14 is independent and the remaining claims all depend from Claim 14. The 
Examiner has objected to Claim 14 for an informality that has been corrected by the 
above amendment as requested by the Examiner. The claims remain otherwise as 
presented previously. 

All of the Claims are rejected under 35 U.S.C. § 102 as being anticipated by U.S. 
Patent Number 6,529,706 to Mitchell (hereinafter: "Mitchell"). This is the only rejection 
the Examiner has made to the currently pending claims. For a reference to anticipate a 
pending claim under § 102, every element of the claim must be taught by the cited 
reference. After reviewing the cited reference again, the Applicant respectfully traverses 
the rejection of every pending claim over Mitchell; Mitchell does not disclose every 
recited element of the pending claim set. 

In particular, the Applicant notes Claim 14 recites several elements that Mitchell 
does not disclose, including: an object comprising executable code for implementing a 
protocol at a satellite; dynamically reconfiguring the satellite to support the OSI reference 
model; executing code for implementing a layer of the OSI reference model; and adapting 
a network layer for at least one of internet protocol and asynchronous transfer mode 
protocol. Failure to disclose any one of these elements would render the Examiner's 
rejection inappropriate under §102. Each of these elements will be discussed in greater 
detail with specific references to the Office Action and the Mitchell reference below. 

The Applicant also notes that Claims 15-18 also recite elements that Mitchell does 
not disclose: wherein the executable code implements a physical layer and a data link 
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layer; wherein the executable code implements a network layer; wherein the executable 
code implements a transport layer; and wherein the executable code implements an 
application layer. Each of these will be discussed in greater detail below as well. In 
addition, it should be noted that as Claims 15-18 depend from Claim 14, every element 
recited in Claim 14 is also part of Claims 15-18. Therefore, Claims 15-18 also lack 
disclosure of every element discussed with respect to Claim 14 as well. 

Finally, the Applicant notes that Claim 20 recites an element that Mitchell does 
not disclose: executing said executable code includes data fusion or packet dropping. 
This will also be discussed below. In addition, Claim 20 also depends from Claim 14, so 
every element recited in Claim 14 is part of Claim 20. Therefore, Claim 20 also lacks 
disclosure of every element discussed with respect to Claim 14 as well. 

Executable c ode for implementing a protocol at a satellite 

Claim 14 recites, in part: "transmitting an object from an earth station to a 
satellite, said object comprising data conforming to at least one protocol and said object 
further comprising executable code for implementing said protocol at said satellite". The 
Examiner notes that Mitchell shows a satellite 240, to which content ultimately to be 
delivered to an airplane is sent (see Figure 1, and also Column 5, lines 57-58). Although 
the Examiner does not identify where in Mitchell the "object" recited in Claim 14 is 
found, the Examiner does make the following statements with regard to specific language 
in Claim 14: 

(a) With regard to the claim language of "data conforming to at least one 
protocol" (Claim 14, line 6), the Examiner states: "it is the Examiner's position that URL 
request would include TCP/IP"; 

(b) With regard to the claim language of "executable code" (Claim 14, line 7), the 
Examiner states: "a unique address code associated with a URL, col. 5, In. 40" (of 
Mitchell) and also "it is Examiner's position that URLs are webpages of HTML code". 

The Examiner appears to suggest that therefore, Mitchell teaches the element of 
"transmitting an object ... to a satellite, said object comprising data conforming to at least 
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one protocol and said object further comprising executable code for implementing said 
protocol at a satellite". The Examiner has made both factual and logical errors in this 
assertion. 

URL as "executable code" 

Firstly, the Examiner makes a factual error in stating that "a unique address code 
associated with a URL" represents "executable code" as recited in Claim 14 is simply 
wrong. An address code such as a URL is NOT executable code. The Examiner 
explicitly relies upon this fallacy a second time by stating "URLs are webpages of HTML 
code". This is also simply not correct. A URL is an address of a webpage; a URL is 
NOT a webpage itself. Similarly, an address code is not executable code; it is descriptive 
of a location. The Examiner has conflated the identifier, i.e. the URL, and the thing 
identified, i.e. the webpage. This is similar asserting that the address of a house is 
equivalent to the house itself. This is clearly not true; sending someone the address of 
your house is quite different from sending someone your actual house. 

Furthermore, even if the Examiner's assertion that a URL is a webpage were true, 
it is also the fact that HTML code is not executable code. HTML code describes a page; 
it is not a set of instructions. As noted in Mitchell itself, web pages are read, stored, and 
viewed, but they are not executed. (See Mitchell, Column 4, lines 12-29.) Mitchell goes 
further to analogize webpages written in HTML to the content of a television broadcast. 
It seems clear that HTML code is being treated as displayable content, not as executable 
code, in the Mitchell reference. 

Executing the code to implement the protocol 

Secondly, the Examiner suggests that the executable code, i.e., the URL, is 
executed to implement the protocol in the Mitchell reference. Specifically, the Examiner, 
as noted above in comment (a), states that protocol is found in the reference because a 
"URL request would include TCP/TP". (The Examiner reinforces this later in the Office 
Action by specifically stating "TCP/IP is network protocol".) Having identified TCP/IP 
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as the "protocol" recited in the claim, the Examiner does not indicate any way in which 
Mitchell demonstrates the URL (identified by the Examiner as the claimed "executable 
code") being executed to implement TCP/IP. Even if one assumes that the "executable 
code" is the webpage itself, rather than the URL of the webpage, Mitchell does not teach 
or suggest in any way that the HTML code of a webpage is executed in some manner to 
implement a TCP/IP protocol. 

While it is possible that information such as HTML data could be carried over a 
network operating using a TCP/IP protocol, this is not the same as using HTML to 
implement the TCP/IP protocol. 

In fact, it makes no sense to implement TCP/IP using HTML code because 
TCP/IP is a protocol associated with a lower level of the OSI reference model than 
HTML. For the HTML data to be received across the network, TCP/IP (or some other 
network level protocol) must already be running. Because of this, there is no way that 
the HTML code could be executed in such a way as to implement the TCP/IP protocol 
that was used to receive the data associated with that piece of HTML code. 

Implementing the protocol at a satellite 

Finally, even if the HTML code were executable, and even if it were used to 
implement TCP/IP or other protocol, the implementation of that protocol via execution of 
the HTML code does not take place "at a satellite ", as recited by this element of Claim 
14. Although the Examiner does cite to a satellite found in the Mitchell reference, see 
reference number 240, and the various code to which the Examiner refers is delivered to 
the satellite, the location at which any HTML code would be interpreted or executed is on 
the airplane, identified as 250 in Figure 1 of Mitchell, NOT on the satellite. Even if the 
URL is considered the "executable code", the interpretation of the URL happens either on 
the airplane or on the ground station; the satellite merely relays the signals between the 
two. 

The Examiner states that "the satellite system 270, 271, 250, 240 in Fig. 2 = 
aircraft network server in aircraft and satellite together". However, by the Examiner's 
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own definition, the airplane (and therefore the aircraft network server in it) is not a 
satellite. The Examiner's cited definition of "satellite" provides two sub-definitions: 
either "a celestial body that orbits a planet" or "an object launched to orbit Earth or 
another celestial body". An airplane as disclosed in Mitchell satisfies neither of these 
characteristics. With regard to the first definition, an airplane is neither a celestial body, 
nor does it orbit a planet. With regard to the second definition, an airplane is not 
"launched to orbit the Earth". 

Even if the Examiner were to suggest that the airplane and the satellite were 
analogous for the purposes of the claim, the rejection would still be improper because it 
was made under §102. Every element of the claim must be shown in the reference to 
anticipate under §102. 

For the reasons discussed above, the element of "transmitting an object from an 
earth station to a satellite, said object comprising data conforming to at least one protocol 
and said object further comprising executable code for implementing said protocol at said 
satellite" is not disclosed, taught, or even suggested by the Mitchell reference. In the 
absence of this element in Mitchell, the Applicants submit that the rejection under §102 
of Claim 14 as anticipated by Mitchell is improper, and request that the Examiner 
withdraw this rejection. As there are no other rejections pending upon this Claim, the 
Applicants submit that this Claim is in a condition for immediate allowance and request 
that the Examiner pass Claim 14 to allowance. 

Dynamically reconfiguring t he satellite to support the OSI reference model 

Claim 14 recites, in part: "dynamically reconfiguring the satellite to support the 
OSI reference model". This element is not found in the Mitchell reference. The 
Examiner directs the Applicant to Column 6, line 8 and lines 11-13 of Mitchell saying "a 
core set of programming is typically delivered to the aircraft regardless if requested or not 
by a client computer. . . . Some webpages are replaced automatically." The Examiner says 
that this represents "dynamic configuration". 
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Firstly, as noted above, the "core programming" described in Mitchell refers to 
content, rather than executable code. Mitchell makes this clear in Column 4, line 24 
where it is noted that "[s]everal broadcasts may be available with different program data 
or media content". "Programming" within Mitchell is clearly descriptive of delivered 
content, rather than executable code. 

Secondly, as also noted above, the dynamic reconfiguration that the Examiner 
says is found in the delivery of a core set of programming is delivered to the aircraft not 
to the satellite. While the content may flow through the satellite, there is no suggestion 
anywhere in Mitchell that the satellite is dynamically reconfigured. Even if the airplane 
(or its network server) were to be reconfigured by the delivery of standard content, the 
reconfiguration of the airplane is not a dynamic reconfiguration of the satellite. 

Finally, as recited in the Claim, the reconfiguration is done "to support the OSI 
reference model". The Examiner cites portions of the Mitchell reference that discuss 
various aspects of the network operating inside the aircraft, including the aircraft network 
server 271 and various Ethernet or serial data buses. While it is possible that the 
communication across this network may be in compliance with an OSI reference model, 
there is no indication given in Mitchell or by the Examiner that any of the reconfiguration 
accomplished by delivering HTML content is used to "support the OSI reference model". 

As noted above, because the HTML content and the interpretation of HTML 
content is something that happens at a high level and relies upon the proper operation of 
the OSI reference model layers below in order for the HTML content to be delivered, it is 
not clear how HTML content can be used to "support" the OSI reference model. 

Because Mitchell does not disclose this element, and the Examiner does not 
indicate how every feature of this portion of Claim 14 is found in the Mitchell reference, 
the rejection of Claim 14 as anticipated by Mitchell is improper; The Applicant therefore 
requests that the rejection of Claim 14 be withdrawn. Because there are no other 
rejections of Claim 14 outstanding, the Applicant submits that Claim 14 is in a condition 
for immediate allowance, and requests that the Examiner pass Claim 14 to allowance. 
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Executing code for implementi ng a laver of the OSI referent mnH P l 

Claim 14 recites, in part: "executing said executable code for implementing at 
least one layer of the OSI reference model". This element is not found in the Mitchell 
reference. With regard to this element, the Examiner states: "it is the Examiner's position 
the URLs are webpages of HTML code". However, this does not demonstrate that this 
element is found in the Mitchell reference. 

The Applicant notes in passing that, as discussed above with respect to other 
elements of Claim 14, the Applicant disagrees with the Examiner's assertions that (a) 
URLs are themselves webpages, and (b) that webpages of HTML code are "executable 
code" as recited in the claim. Each of these reasons is sufficient to demonstrate that this 
element is not taught by Mitchell. 

In addition, the Examiner does not indicate where in Mitchell it is shown that the 
execution of URLs or HTML webpages implements any layer of the OSI reference 
model. The Examiner suggests that the "network layer" of the OSI reference model is 
implemented, and states that "TCP/IP is network protocol". However, despite references 
to TCP/IP in the Mitchell reference, the Examiner does not point out any portion of 
Mitchell that shows that HTML webpages or URLs are used to implement TCP/IP. No 
such teaching can be found anywhere in Mitchell. 

Furthermore, as noted above with respect to the issue regarding "support" of the 
OSI reference model, the "execution" of URLs or HTML code takes place at a level that 
itself relies upon the operation of the network protocol layer of the OSI reference model. 
Nothing executed at the level of URLs or HTML content is used to implement the 
network layer of the OSI model, because the network layer is below the level at which 
URLs and HTML content are handled. 

Because Mitchell does not disclose this element, and the Examiner does not 
indicate how the network protocol layer can be implemented using "code" that resides at 
a level that itself depends upon the network protocol layer, the rejection of Claim 14 as 
anticipated by Mitchell is improper. The Applicant therefore requests that the rejection of 
Claim 14 be withdrawn. Because there are no other rejections of Claim 14 outstanding, 
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the Applicant submits that Claim 14 is in a condition for immediate allowance, and 
requests that the Examiner pass Claim 14 to allowance. 

Adapting a network laver ... 

Claim 14 recites, in part: "adapting said network layer for at least one of internet 
protocol and asynchronous transfer mode protocol." This element is not found in the 
Mitchell reference. With regard to this element, the Examiner is silent, apart from the 
statement "TCP/IP is network protocol". However, neither the reference nor the 
Examiner's rejection shows how TCP/IP is "adapted" by the execution of the Exemier's 
cited "executable code", i.e., URLs or HTML webpages. 

The Applicant notes in passing that, as discussed above with respect to other 
elements of Claim 14, the Applicant disagrees with the Examiner's assertions that (a) 
URLs are themselves webpages, and (b) that webpages of HTML code are "executable 
code" as recited in the claim. Each of these reasons is sufficient to demonstrate that this 
element is not taught by Mitchell, because without executing executable code to perform 
the function of "adapting said network layer", the element is not present. 

In addition, the Examiner recites the entirety of this claim element, but only states 
that "TCP/IP is network protocol" without suggesting how Mitchell discloses the 
execution of URLs or HTML to adapt TCP/IP in any way. This is because Mitchell is 
silent on this issue. 

Also, as discussed above with respect to the "executing said executable code" 
element, "execution" of URLs or TCP/IP does not support the "adapting said network 
layer" because "execution" of URLs or HTML code takes place at a level that itself relies 
upon the operation of the network protocol layer. 

Because Mitchell does not disclose this element, and the Examiner is silent as to 
where in Mitchell the step of "adapting said network layer" is to be found, the rejection of 
Claim 14 as anticipated by Mitchell is improper. The Applicant therefore requests that 
the rejection of Claim 14 be withdrawn. Because there are no other rejections of Claim 


-11- 


Application No. 09/584,955 

Amendment dated 9 June 2006 

Reply to Office Action of 15 March 2006 


RD-26450/USA 


14 outstanding, the Applicant submits that Claim 14 is in a condition for immediate 
allowance, and requests that the Examiner pass Claim 14 to allowance. 

Elements found in Claim 15-18 

Claim 15 recites, in part: "wherein said at least one layer comprises a physical 
layer and a data link layer". Claim 16 recites, in part: "wherein said at least one layer 
comprises a network layer". Claim 17 recites, in part: "wherein said at least one layer 
comprises a transport layer". Claim 18 recites, in part: "wherein said at least one layer 
comprises an application layer. 

While the Examiner rejects each of these claims on the basis that these layers are 
themselves inherent in the OSI reference model, the Examiner does not show how the 
features associated with any of these claim elements are found in the Mitchell reference. 
This will be discussed in greater detail below. 

The Applicant acknowledges that the OSI model includes multiple layers, 
including the layers recited in these claims. However, the Examiner has not shown where 
the claimed element is shown in Mitchell. Taking the element recited in Claim 17 for 
example: "said at least one layer comprises a transport layer". This language does not 
merely require that a transport layer exists, but that the transport layer also meets all the 
elements of the parent independent claim (Claim 14) recited as related to "the at least one 
layer". By merely pointing out that "a transport layer" was known, the Examiner has not 
demonstrated that the element of the claim is shown in the reference, as is required under 
§102. 

In particular, the "transport layer" as recited in Claim 17 must not merely exist, 
but must also be part of the "at least one layer", which, as recited in Claim 14 "executing 
said executable code" will result in implementing. Not only is Mitchell silent with regard 
to the "transport layer" itself, but Mitchell does not teach any way for execution of URLs 
or HTML content to implement the transport layer. 

The same is true for the elements recited in Claims 15, 16, and 18. These 
elements must not merely exist, but must satisfy the features recited for the "at least one 
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layer" from Claim 14, the parent claim of each of these dependent claims. The Examiner 
has not indicated anywhere in Mitchell that these elements are shown, and in particular 
has not indicated how the execution of URLs or HTML code will result in the 
implementation of any of these layers. 

Furthermore, as discussed above, since these layers are part of what supports the 
URL and HTML levels, it is not clear how these layers could be implemented using 
URLs or HTML code that itself relies upon these layers of the OSI reference model. 

In addition, each of dependent claims 15-18 include every element of Claim 14, 
which as discussed above, includes at least four elements not taught by Mitchell. 

For each of these reasons, Claims 15-18 are not anticipated by Mitchell. The 
Applicant therefore requests that the rejection of Claims 15-18 be withdrawn. Because 
there are no other rejections of these Claims outstanding, the Applicant submits that 
Claims 15-18 are in a condition for immediate allowance, and requests that the Examiner 
pass these claims to allowance. 

Elements found in Claim 20 

Claim 20 recites, in part: "said step of executing said executable code includes at 
least one of the steps of data fusion and packet dropping". Although "data fusion" and 
"packet dropping" are suggested in the Mitchell reference, as the Examiner notes, 
Mitchell does not teach or suggest that either of these processes is performed by the 
execution of URLs or HTML code, as the Examiner suggests. 

Specifically, the portion of Mitchell to which the Examiner refers (Column 8, 
lines 50 and 54) discusses processes that may be used to handle information that needs to 
be broken up for transmission at the network layer level. This is made clear by the 
discussion in Mitchell cited by the Examiner. No suggestion is made that either of these 
processes (i.e., packet dropping or data fusion) are implemented via the execution of 
URLs or HTML code. 

In fact, as noted above with respect to the other aspects of the OSI reference 
model that are at a lower level than the "executable code" which the Examiner identifies 
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in Mitchell, the processes of data fusion and packet dropping take place in order to make 
sure that URLs and HTML code is properly delivered to the airplane. 

In addition, Claim 20 includes every element of Claim 14, from which it depends. 
As noted above, Claim 14 includes at least four elements not taught by Mitchell. 

Because Mitchell does not disclose the execution of URLs or HTML content (the 
items cited as "executable code" by the Examiner) to perform either data fusion or packet 
dropping, Claim 20 includes elements not found in the cited reference, and therefore, the 
rejection of Claim 20 under § 102 is improper. The Applicant therefore requests that the 
rejection of Claim 20 be withdrawn. Because there are no other rejections of Claim 20 
outstanding, the Applicant submits that Claim 20 is in a condition for immediate 
allowance, and requests that the Examiner pass Claim 20 to allowance. 

Conclusion 

In light of the amendments and remarks presented herein, Applicant submits that 
the case is in condition for immediate allowance and respectfully requests such action. If 
any issues remain unresolved, the Examiner is invited to telephone the Applicant's 
counsel at the number provided below so that a resolution can be most effectively 
reached. 



Richard A. DeCristofaro 


Attorney for Applicant 
Registration No. 51,601 

Telephone: (518)387-5832 

Schenectady, New York 

Date 
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